[Previous] [Next] [Index]
[Thread]
Re: SSL and certificates
You are correct that the security that can be provided is limited if only one
of the parties has a certificate. But it's not quite as bad as you think.
> How can these products be considered secure if one party
>does not have a digital certificate?
>
>These are the implications as I see them (let me know if I am way off
> base here..)
>
> 1. The session key is not transferred securely when one party does not
> have a digital certificate. A bad guy could swipe the session key and
> "decrypt" data being transferred between the legitimate parties.
If the end without a certificate chooses a session key and encrypts it under
the public key of the end that has a certificate, and eavesdropper can't
recover the key. The end without the certificate knows that it is talking with
the party that is named in the certificate, that secret data it sends will go
only to that party and that data it receives originated with that party. The
party with the certificate does not know who it is talking to.
>
> 2. Both parties can not be authenticated.
That's correct.
>
> 3. Uninformed users are being lulled into a false sense of security.
>
That's probably true.
One more tidbit is useful. Password based authentication of a user over an SSL
or SHTTP encrypted connection to a server with a public key certificate is a
powerful combination. The password can not be picked up by an eavesdropper
because of the encryption, and the resulting authentication is as good as
dual-certificate authentication (so long as the user password is sufficiently
random, used with only a single server, and distributed to user and server
securely initially).
--Charlie Kaufman
(charlie_kaufman@iris.com)
Follow-Ups: